Mule's configuration is extensible in that there is no mandate about how the configuration of Mule should be stored or the format of the configuration. The only requirement is that once mule is configured an instance of UMOManager should be available by calling MuleManager.getInstance().

Quick Start

To start a Mule Instance from the command line or script using a Mule XML configuration file, use the following -

java -cp ... org.mule.MuleServer -config ../conf/mule-config.xml

This will use the default org.mule.config.MuleXmlconfigurationBuilder to process configuration file called ../conf/mule-config.xml.

The equivilent code example would be -

MuleXmlConfigurationBuilder builder = new MuleXmlConfigurationBuilder();
builder.configure("../conf/mule-config.xml");

Loading Multiple Configurations

Developers can specify a comma-separated list of XML configuration files to load i.e.

java -cp ... org.mule.MuleServer -config ../conf/mule-config.xml,
../conf/mule-component1-config.xml,../conf/mule-component2-config.xml

The equivilent code example would be -

MuleXmlConfigurationBuilder builder = new MuleXmlConfigurationBuilder();
String configs="../conf/mule-config.xml,
../conf/mule-component1-config.xml,../conf/mule-component2-config.xml";
builder.configure(configs);

The configuration files are loaded in sequences so global configuration files should be loaded first.

Other Configuration Builders are available such as Spring and Groovy.

Configuration Builders

To configure Mule a Configuration builder is used. This is a simple interface that the Mule server can invoke on start up. You can define your own configuration depending on how you want to configure Mule. Mule currently comes with three configuration builder, the default Mule xml Configuration Builder, Spring and Groovy Builders. However, it would be straight forward to implement other builders, say a Pico builder or BeanShell builder.

To tell Mule to use a particular builder you must specify the fully qualified class name as a command line argument using the -builder token and define the configuration resources for the builder using the -config token. For example to use the Spring builder, you would define your cha command something like this -

java -cp ... org.mule.MuleServer
-builder org.mule.extras.spring.config.SpringConfigurationBuilder
-config ../conf/applicationContext.xml

Mule Xml Configuration

By default Mule's configuration is an xml file, usually called mule-config.xml. This file has a corresponding DTD called mule-configuration.dtd which is included in the distribution.
The root of all configurable elements in Mule is the UMOManger, which defines a hierarchy of configurable objects. The general structure is described in the figure below, though for a complete picture of Mule configuration refer to the Mule Configuration Reference guide.

Spring Configuration

As well as the default Mule xml configuration, a Spring configuration builder is included with the Mule distribution. This builder enables the developer to configure all Mule elements through Spring, which means that any Mule objects can leverage Spring's AOP and transaction interceptors, DAO support, etc.

For more information about configuring Mule with Spring see the Spring chapter.

Rolling your own configuration

Mule currently comes with two configurations builders, the default Mule Xml builder and a Spring builder.
Writing your own configuration builder is a simple task of writing an instance of org.mule.config.ConfigurationBuilder. This interface defines a single method -

public UMOManager configureMule(String configResources)
throws ConfigurationException;

where configResource can be anything from a JNDI location, a URL or a filename (or comma separated list of filenames) on the classpath or file system. It's up to the Configuration Builder how it uses the configResource to construct an instance of UMOManager and pass it back to the server.

Some future Configuration Builders may include a PicoContainer assembler, a Bean Shell builder and Jndi builder.

See also Configuration Options for details about how to configure the actual mule instance.

Overloading the UMOManager

The UMOManager interface defines the central location for all configured objects. Mule defines a default implementation of the UMOManager, the MuleManager. However, it is possible to provide your own implementation of UMOManager. There are two ways to use your own UMOManager -

1. Set the VM parameter to a fully qualified class name of the UMOManager you want to use, i.e. -Dorg.mule.umo.UMOManager=com.foo.MyManager.
2. Use the MuleManager.setInstance(...) method. This method is useful when defining your own ConfigurationBuilder; this is discussed more in the next section.